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other embodiments, the user presence information is published, such as published via a 

presence application server. 

In accordance with another embodiment of the invention, a method is 
provided for routing communication requests targeted for a user over a network including 
an IP Multimedia core network Subsystem (MS) network. The method includes 
subscribing a Serving Call Session Control Function (S-CSCF) to user presence 
information published on the network. A notification(s) is received at the S-CSCF 
indicating a state of the user presence information. The S-CSCF creates a routing script 
based on the state of the presence information. Communication requests targeted for the 
user and received at the S-CSCF are routed to one or more destinations as dictated by the 
routing script. 

In more particular embodiments of such a method, attributes of the 
communication requests received at the S-CSCF are identified, and routing of such 
communication requests to a destination(s) involves routing the communication requests as 
dictated by the routing script and depending on the attributes of the communication 
requests. Such attributes may include, for example, a caller identity, a caller domain, a 
caller equipment type, a communication request priority, a communication request type, 
etc. In other embodiments of the invention, subscribing and notifying are accomplished 
using SP, such as through the use of SIP SUBSCRIBE and NOTIFY methods. The 
routing script in one embodiment is created via a scripting language, i.e., where a program 
is created to cause the incoming communication requests to be routed according to the user 
presence information upon execution of the program. In another embodiment, the routing 
script is created as a data structure that provides routing actions for each association of user 
presence information and communication request attributes. 

In accordance with another embodiment of the invention, a network entity 
is provided for routing communication requests targeted for a user over a network. The 
network entity includes a processor, which may include one or more processing 
devices/components. A subscription module operable with the processor is configured to 
subscribe to user presence information published on the network. A notification 
management module operable with the processor is configured to receive notifications of a 
state of the user presence infoimation. A routing instruction generation module operable 
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PPT ATT nPSrRTPTTQN thf. TNVENTION 
In the following description, reference is made to the accompanying 
drawings which form a part hereof, and in which is shown by way of illustration various 
embodiments in which the invention may be practiced. It is to be understood that other 
5 embodiments may be utilized, as structural and operational changes may be made without 
departing from the scope of the present invention. 

A portion of the disclosure of this patent document contains material which 
is subject to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure, as it appears in the 
10 Patent and Trademark Office patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

Generally, the present invention provides a system, apparatus, and method 
for routing communication requests. A proxy or other server, configured to assist in 
managing sessions between networked devices, subscribes to the presence information of 

15 users of such networked devices. When the proxy/server receives notifications of presence 
information, it formulates a plan or "script" for routing calls according to the presence 
information. When a communication request arrives at the proxy/server for a particular 
networked device(s), the proxy/server applies the script in order to route the request to the 
destination that the user has identified via the presence infonnation. 

20 FIG. 1 is a block diagram illustrating a representative network system 

employing principles of the present invention, hi the illustrated embodiment, a network 
100, which may include multiple interoperative networks, is used to communicate 
information betweenentities capable of communicating overthenetwork(s) 100. The 

network 100 may include one or more proxies 102, 104, 106, and one or more session 
25 management proxies or servers 108. The proxies 102, 104, 106 represent network entities 
that at least provide a point of contact for associated communication devices. The session 
management proxy/server 108 represents a network entity that at least performs session 
management fiinctions for the network 100 or network subsystem. Any number of 
different communication devices 110, 112, 114, 116 may communicate information over 
30 the network 100. These communication devices may be any type of communication 
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devices, including landline devices such as workstations, desktop computers, portable 
computers, or any other computing/communication device capable of comiecting to the 
network 100. The communication devices may also be mobile/wireless devices, such as 
the wireless device 1 10, which may include mobile phones 118, Personal Digital 
Assistants (PDAs) 120, portable computing devices 122, or any other device 124 capable 
of wireless communication with the network(s) 100. 

In accordance with one embodiment of the invention, the session 
management proxy/server 108 subscribes 126 to the presence information of a user, such 
as the user of device 1 10. Generally, presence refers to the willingness and/or ability of a 
user to communicate with other users over a network. A variety of different preference 
indicators may be associated with a user's preference, such as user availability, comiection 
status, various user identities, device capabilities, and the like. A subscription 126 
generally refers to a mamier in which a network entity can estabUsh its interest in obtaining 
notification messages relating to particular events. In the illustrated embodiment, such 
events relate to the publication and/or modification of user presence information. 

In the illustrated embodiment of the invention, the session management 
proxy 108 subscribes 126 to this presence information via a presence application server 
(AS) 127. More particularly, the user of device 1 10 may register 128 to the network 100 
or network subsystem, which may result in a session management server 108 being 
assigned to that user. The user's presence information is pubUshed via the presence AS 
127. For example, a publication message (e.g., SIP PUBLISH message) may be sent 129 
from the device 110 to the presence AS 127, where the publication message includes the 
user's presence information. The device 1 10 may include a pubUcation module (not 
shown), such as a processor executing appropriate software instructions, to create the 
appropriate pubHcation message. While the publication message 129 is illustrated as being 
directly sent to the presence AS 127, such a message 129 would in fact be provided to the 
presence AS 127 by way of the appropriate proxies within the network 100, including the 
session management proxy 108. When the presence AS 127 receives original or modified 
presence information, it can notify any subscribers to that information, as described more 
fully below. 
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Upon assignment of the session management server 108 to the user, the 
session management server 108 subscribes 126 to the presence AS 127 associated with that 
user. It should be noted that the presence session management proxy 108 and presence AS 
127 may be implemented in separate network entities, or may be co-located (i.e., both 
functional modules residing in a common location/housing). Where these functions are co- 
located, the subscription 126maybeperformedby way of internal functionality. For 
example, the subscription may be made by sending internal messages, communicating via 
a communication protocol between devices at the co-located entity, through direct links, 
etc. In another embodiment of the invention, a session management proxy 108 may 
subscribe to such presence information at a different server or at the device 110 itself if 
they are capable of providing resulting notifications. 

When the session management server 108 receives a notification(s) 130 of 
presence information, the session management server 108 (or another entity operating 
under the direction of the session management server 108) creates a script 132 for routing 
calls, messages, or the like, according to the presence information. If the presence 
infomiation changes, corresponding notifications 130 are sent to tiie subscribing session 
management server 108 in accordance with one embodiment of tiie invention. Again, 
where the session management proxy 108 and presence AS 127 are co-located, such 
notifications 130 are "sent" internally, and may be internally communicated in any known 
fashion, m this mamier, the session management server 108 is kept apprised of the current 
presence information for the user of the device 110, and the appropriate routing script 132 
is created and maintained at the session management server 108. 

When a request 134 from a device such as mobile device 1 16 and targeted 
for the user device 110 arrives at the session management server 108, the session 
management server 108 applies the routing script 132 to the request 134 in order to route 
the request to tiie destination according to the script 132. For example, assume tiie user of 
device 1 10 established presence infomiation indicating that voice calls not associated with 
a predetemiined address domain are to be treated as "busy." Upon terminal 110 
registration 128 to tiie network 100, tiiis presence information can be published, and the 
assigned session management server 108 can subscribe 126 to tiie presence information by 
way of tiie presence AS 127. When a notification 130 of tiiis presence mformation is 
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FIG. 3 is a block diagram illustrating one embodiment of the presence- 
based routing in accordance with the present invention. In the embodiment of FIG. 3, the 
presence-based routing is implemented in an IMS enviromnent. While IMS systems and 
components are known to those skilled in the art. a brief description of such an 
enviromnent is set forth below. 

IMS is an architecture for supporting multimedia services, which is 
currently specified to support such multimedia services via the Session Initiation Protocol 
(SIP) infirastructure. The IMS includes several network entities including signaling/session 
control elements, and database and application servers. The session control elements are 
generally referred to as Call Session Control Functions (CSCFs). These CSCFs are logical 
functions performed by the network, and include Proxy CSCFs (P-CSCF), Intenrogating 
CSCFs (I-CSCF), and Serving CSCFs (S-SCSF). 

The P-CSCF is the first contact point within the IMS that is seen by the 
user's User Equipment (UE), or more particularly by the User Agent (UA) of that UE. In 
an IMS network, services are performed for a user in his/her home network (also referred 
to as a home domain). If the user is roaming outside the home network and is therefore in 
a visited network, the UA's first point of contact is with the P-CSCF in the visited 
network, which then communicates with other CSCFs in the user's home network. One 
task of the P-CSCF is to provide user registrations to the user's home network in order to 
locate the CSCFs assigned to the user. More particularly, the P-CSCF may forward 
registrations to the I-CSCF in the user's home network, where the I-CSCF is a contact 
point to the user's home network. The I-CSCF is responsible for locating the appropriate 
S-CSCF by contacting the Home Subscriber Server (HSS) associated with the user's home 
network and obtaining the address of the S-CSCF. The S-CSCF performs the session 
control, registration, and otheir services for the subscriber in the subscriber's home 
network. 

The 3GPP IMS utilizes SIP in order to achieve a wide range of fimctionahty 
with the network. SIP, defined by the hitemet Engineering Task Force (IETF), is an end- 
to-end signaling protocol that facilitates (among other things) the establishment, handling 
and release of end-to-end multimedia sessions. It can be used in a wide variety of 
applications, including presence applications. Sff enables network endpoints or "User 
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Agents" (UA) to discover one another and to agree on a session characterization. UAs 
refer to the network endpoints that initiate SIP requests to establish media sessions, and to 
transmit/receive information. In order to locate other users, SIP utilizes the 
aforementioned infrastructure of network proxy servers such as the P-CSCF, I-CSCF and 
S-CSCF to which users can send registrations, invitations to sessions, and other requests 
via their terminals. 

Referring now to FIG. 3, an exemplary embodiment of the present invention 
in an IMS enviromnent is described. A first UA, terminal-Al 300, registers 302 to the S- 
CSCF 304 of the user's home network. For example, a SIP REGISTER message may be 
sent to the nearest P-CSCF (not shown) for that user, where the nearest P-CSCF may be 
located using Domain Name Service (DNS) SRV, Dynamic Host Configuration Protocol 
(DHCP), or the like. If the P-CSCF is in a visited network, the P-CSCF locates the I- 
CSCF of the home network for the user, and sends a REGISTER message 302 to the S- 
CSCF 304. Upon registration of terminal-Al 300, the S-CSCF 304 can subscribe 306 to 
the user's presence information at the presence appUcation server (AS) 308. Other 
terminal appUcations, terminal-A2 3 10 also register 3 12 to the S-CSCF 304. 

Terminal-Al 300 publishes 314 its presence information via the presence 
AS 308. In response to the previous subscription 306, the presence AS 308 generates a 
SIP NOTIFY message 316 to the S-CSCF 304 to notify it that the presence state of the user 
at terminal-Al 300 has changed. Using the new presence state, the S-CSCF 304 
creates/modifies the routing script to correspond to the presence state of the user at 
terminal-Al. 

At some point, another user may want to estabUsh communication with 
terminal-Al 300. An incoming request to estabUsh such communication, such as via a SIP 
INVITE request 318, is received at the S-CSCF 304 in the home network of the user of 
terminal-Al 300. Based on the presence state of the user, the INVITE request is routed 
320 to terminal-A2 310 whose presence information indicates that it is available in the 
illustrated embodiment. The presence information of the user at terminal-Al 300 could 
subsequently change, thereby resulting in subsequent INVITE requests 3 1 8 being routed to 
the terminal-Al 300, or to another terminal/destination. 
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FIG. 4 is a flow diagram illustrating one embodiment of a manner of 
routing communication requests in an IMS environment in accordance with one 
embodiment of the present invention. In the illustrated embodiment, the user registers 400 
to the IMS network. When the user registers, the standard behavior of the IMS is that the 
user is assigned an S-CSCF. The user may optionally publish 402 his/her presence 
information, and the S-CSCF may subscribe 404 to the presence information of the user. 
Whether the user's presence information is pubUshed 402 is a decision to be made by the 
user. Similarly, the particular S-CSCF may or may not be configured to subscribe 404 to 
the pubUshed presence information of that user or other users. If the S-CSCF receives no 
notification of presence information as determined at decision block 406, and the S-CSCF 
were to receive a request (e.g., INVITE) targeted for the user as determined at decision 
block 408, the S-CSCF would simply use standard routing 410. This could occur, for 
example, if the user did not publish his/her presence information and/or if the S-CSCF did 
not subscribe to the presence information. However, in accordance with the present 
invention, receipt of a notification as determined at decision block 406 results in the S- 
CSCF creating 412 a script to route calls (including voice, messages, etc.) according to the 

presence information. 

At any time, the presence information may change. For example, the user 
may move to a different location, or an event may change causing the user's presence 
information to be updated. If the presence information changes as determined at decision 
block 414, the S-CSCF will update 412 the script to route the calls according to the 
updated presence information. When the S-CSCF receives a request (e.g., INVITE) 
targeted for the user as determined at decision block 416, the S-CSCF applies 418 the 
script in order to route the request to the destination according to the presence information. 

as directed by the script. 

FIG. 5 is a message flow diagram illustrating one representative manner in 
which a user may register to an S-CSCF. The embodiment shown in FIG. 5 assumes that a 
mobile user using UE 500 communicates with the IMS network by way of a General 
Packet Radio Service (GPRS) network. The UE 500 initially does not know the address of 
the P-CSCF 502 to perform a SIP registration, and performs the appropriate fimctions 504 
to set up a data connection. The UE 500 performs GPRS Attach procedures and 
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establishes a Packet Data Protocol (PDP) context, which establishes the path to carry SIP 
messages to the P-CSCF 502. More particularly, the UE 500 sends an Attach message to a 
Serving GPRS Support Node (SGSN; not shown) that includes a subscriber identifier. 
After certain authentication and profile procedures, the SGSN completes the Attach 
procedure and provides an Attach Complete to the UE 500, and the location of the mobile 
UE 500 is now known to the network. Once attached, the UE 500 activates a PDP address 
that sets up an association between the SGSN and the Gateway GPRS Support Node 
(GGSN) 506. As is known in the art, a GGSN acts as a gateway between the GPRS 
network and a packet switched public data network, such as an IMS network. The GPRS 
allows mobile subscribers to access the data network or specified private IP networks 
through a standard protocol, such as the Internet Protocol (IP). Establishing a PDP 
context, which identifies the association between the SGSN and GGSN, activates an 
address for the UE 500 so that the UE 500 can communicate using that address. Further, 
the P-CSCF 502 may be located using Domain Name Service (DNS) SRV, Dynamic Host 
Configuration Protocol (DHCP), or the like. 

When the UE 500 has attached to the GPRS network, a PDP context has 
been estabUshed, and the P-CSCF 502 has been located, the UE 500 needs to register to be 
able to set up SIP sessions. The registration process informs the IMS network where the 
UE 500 is. More particularly, the UE 500 needs to have an S-CSCF 508 fi-om its home 
network assigned to the UE 500. This registration process is first depicted via registration 
path 5 10 between the UE 500 and the P-CSCF 502, where a SIP REGISTER message is 
sent. The REGISTER message includes information such as the identity of the subscriber 
and a domain name for the user's home network. Using this information, the P-CSCF 502 
determines the entry point to the user's home network. The present example assumes that 
an I-CSCF 512 is used as the entry point to the user's home network; i.e., the user is not 
located in his/her home network. Therefore, the P-CSCF 502 discovers the I-CSCF 512 
with the assistance of other network entities such as the DNS. The P-CSCF 502 sends the 
REGISTER message 5 14 to the I-CSCF 512 with the appropriate information. The I- 
CSCF 512 queries 516 the HSS 518 to identify the S-CSCF 508. The I-CSCF 512 can 
determine the address of the HSS 518 using information fi-om the received REGISTER 
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message 514. The I-CSCF 512 determines the address of the S-CSCF 508, and sends the 
REGISTER message 520 to the S-CSCF 508. 

The S-CSCF 508 and HSS 51 8 may communicate information 522 to 
register the user and to get user profile and security parameters. Where no authentication 
is required for registration, the S-CSCF 508 may respond to the REGISTER message 520 
with a confirmation message that registration is complete, such as a "200 OK" response. 
Where registration with authentication is implemented, the S-CSCF 508 may request 
authentication credentials, such as by sending a "401 (Unauthorized)" response back to the 
UE 500 as shown on paths 524, 526, 528. The UE 500 then sends a new REGISTER 
message 530 using its authentication credentials obtained via the security association 532. 
The REGISTER message 534 is then sent from the P-CSCF 502 to the I-CSCF 512, which 
queries 536 the HSS 518 to identify the S-CSCF 508, and sends the REGISTER message 
538 to the S-CSCF 508. The user is registered 540, and the S-CSCF 508 sends a 
registration/authorization complete message, such as the "200 OK" messages shown on 

paths 542, 544, 546 back to the UE 500. 

The UE 500 may then subscribe 548, 550 to events, such as an event 
package for registrations (EVENT: REG). User agents can create, modify, and delete 
registrations, and administrators can also modify registrations to enforce policy. 
Therefore, the UE 500 may want to be notified of such registration state changes. The 
subscription 548, 550, and resulting "200 OK' 552, 554 response establishes such a 
subscription. M this mamter, the S-CSCF 508 may notify (e.g., SIP NOTIFY) 556, 558 the 
UE 500 with changes in registration state, to which the UE 500 will acknowledge 560, 
562. 

The above registration procedure is a description of one general registration 
scenario that may be utilized in comiection with the present invention. However, any 
known registration methodology may be implemented. Details on such GRPR attach, PDP 
context, and SIP registration procedures are known in the art and are not fiirther presented 
here. 

FIG. 6 is a message flow diagram illustrating an exemplary embodiment for 
subscribing an S-CSCF to the presence information for a user. In the illustrated 
embodiment of FIG. 6, a registration process is performed such as that described in 
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connection with FIG. 5. In FIG. 6. the registration process is depicted between User-A 600 
and S-CSCF 602. with the P-CSCF 604 and I-CSCF 606 involved as previously described. 
Briefly, a registration request such as a SIP REGISTER message is passed 610. 612. 614 to 
the S-CSCF 602, and the S-CSCF 602 responds with a request for authorization credentials 
(assuming registration with authorization) as illustrated by the "401 (Unauthorized)" 
responses 616. 618, 620. User-A 600 then registers 622, 624, 626 with the proper 
authentication credentials, and the S-CSCF 602 responds with a message (e.g., "200 OK") 
628. 630, 632 indicating that the authentication is verified and the registration is complete. 

At some point. User-A 600 may publish 633 the presence information to the 
presence AS 636. such as by issuing a SIP PUBLISH request. This can occur at any point 
in time, and is not temporally limited to the point in time as illustrated in FIG. 6. For 
example, User-A 600 may publish 633 presence information after the S-CSCF 602 
subscribes 634 to the presence information of User-A 600, or beforehand as shown in the 
illustrated embodiment. The presence AS 636 may respond with an appropriate message, 
such as the 200 (OK) message 635. In any case, the S-CSCF 602 initiates a subscription to 
the presence information of User-A. such as by issuing a SUBSCRIBE request 634 to a 
presence application server (AS) 636. It should be noted that the S-CSCF 602 and 
presence AS 636 may be implemented in separate network entities, or may be co-located. 
In response to the subscription request, the presence AS 636 responds with a message, 
such as a "200 OK" message 638, indicating success of the subscription. The presence AS 
636 maintains the presence information/state of User-A 600. The presence AS 636 then 
provides a notification to the S-CSCF 602, such as a SIP NOTIFY message 640, providing 
the initial presence information for User-A 600. The S-CSCF 602 responds to 
acknowledge receipt of the NOTIFY 640 message, such as by sending a "200 OK" 
response 642. Further changes in the state of the presence information of User-A will 
result in additional NOTIFY 640 messages being sent from the presence AS 636 to the S- 
CSCF 602. Using the presence information, the S-CSCF 602 can create the routing script 

previously described. 

The routing script in accordance with the presem invention may be created 
in any number of mamiers. FIGs. 7A and 7B illustrate representative routing scripts 
according to the present invention, where the actual script is programmed in a mamier 

16 



NC 368 16 US 
NOKM.066PA 
Patent Application 



suitable for the environment in which it is used. The routing scripts shown in FIGs. 7A 
and 7B are provided to illustrate examples of routing scripts, and an actual routing script 
will depend on at least the particular presence information provided and the programming 
language implemented. Therefore, the routing script examples of FIGs. 7A and 7B are 
provided for illustrative purposes only, and the routing scripts according to the present 
invention are clearly not limited to the specific examples shown in FIGs. 7A and 7B. 

The routing script created at the S-CSCF or other session management 
server is based on user presence information. For purposes of the example of FIG. 7A, it is 
assumed that the user's presence information is as shown in Table 1 A below. 



Presence Item 


Presence Status 


Mobile-phone voice 


• Status "available" for callers from ExampleDomain.com 

• Status "busy" for all other callers 


Mobile-phone video 


• Status "busy" for all callers 



Table lA 

The user's presence information in this example provides presence status for two presence 
items. The first presence item relates to voice communications for the user's mobile 
phone. The current presence status indicates that the user is available to receive calls from 
callers having an address from "ExampleDomain.com." The presence status is "busy" for 
all other mobile-phone voice calls. For mobile-phone video communications, the status is 

"busy" for all callers. 

This embodiment therefore illustrates that there may be different presence 
information to subscribers from different domains. This is more evident by re-presenting 
the presence information as shown in Table 1 B below: 
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Presence Status 



. ExarapteDomain; available on mobile phone 
• Other domains: busy 
All domains: busy 



Table IB 

When the S-CSCF receives such presence information (e.g., from a 
presence AS or o,herne,wor.en.iW.i.isconve«edi„.o.arou«„gscriptBycreatin8 S^ 
5 aI.,ngscrip,at.heMSne.wor.,«,.user.spresenceinforma.ion»il.beco— 
rcrJsh.he.MSnetvvorlc.ba..edirec.edt„.ha.user. Otherwise, wtthout the 
leIf.heprese„t.nve„tion,auserc„uMse.his/berpresenceinfonna.ionat.hemoM^ 

nce,bu.wou.dsU.lr.eiveunwan.ed cans or other sessioninitiationre^uests^^^^^^^ 
lo*aoesnot.a.e.heuser.spr.sences.atusi„toconsiaeraUon.Fur.her,«,*o„r*e^ 
,0 benefitof.hepresen.invention,theuserwouldhave.ocreatehis/herownscnp.s The J 
om!ne.worLasedrou«ngscripta,describedhereinprovidesaddi.ionaladv.^^^^ 

FIG 7A illustrates an example routing script 700 for the presence 
informatton shown in Tables 1 Am. which can be ^gr^med in any appropnate 
,5 language, implemented in hardware, or implemented using a combmatton t— a^d 
m A first segment 702 of the routing script 700 is directed to mobtle-phone vo.ce 
rr:^^callersr^mthedomain"Examp.eOom.„.com..Mftbecal,erdom.n,s 

Cp.eDomain.com" andthecalUypeis"voice...then.heca,lwillberouted.othe 
u!:Tlbilepho„e.Morepar.icularly,U,eca.lmayberoutedto.heS. address 

" xvhere 'hiser" identifies the user, and 
20 ••sip:user@mobilcphone.operator.com, where -user id 

..„obilephonc" identifies the destinatton at the domain "operator.com. Th«efor^ >f a 
v:i!lsreceivedfi.m.forexample,ca.ling„serWeOomain.com,th^^^^^^^^^^ 

be me. and the call will be routed to "sip:user@mobilepho„e.opera.or com. 

A second segment 704 of the routing script 700 is dtrected to mobtle-phone 
,5 „on-voicecallswherecallersare&omthedomam"ExampleDomain.com."If.hecaller 
::Iis«eI>omain.com"and.hecalltypeisnot..oice,".hen«,enon-votcecal. 
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20 



, . ,,stem More particularly, the non-voice call may be 
will be routed to the user's voicerr^ail systerr.. M P ^^^^^ 
.uteatotheSlPadaress"sip:user@PDA.^^^^^^ 

3,owntosuchcanersrnay^^^^^^^^^^ 
ifavideocalhsrecetvedfrorn ah u o 

causethevideocalltoberoutedto sip.user@PDA ^ ^^^^..^i^^d 
Itshouldbereco^izedthatother.anr.ersofro..^^a^^^^^^^^^^ 

.stinationrnaybeirnple.ented,su.as.^^^^^^ 

,0.thenathirdse^ent.Oeo.theroutin.s..^^^^^^^ 
ai.ectedtoaUc.ls.orncaUerdorna— 
dorr.ainisnot-ExampleDomam.com, then he call 
Morep— themayb— 

"sip:user@voicemail.operator.com, where „ T,,,,fore, if a call is 

identifies the voicemail destination atthedomamopera^on^^^^ 

received from, for example, callinguser@OtherDomam.com, the 

«sip:user@voicemail.operator.com." ntustrated in FIG. 7B. For purposes 

Another representative routmg scrtpt rs Ulustrated m 
, f mr 7B it is assumed that the user's presence information is as 
of the example of FIG. 7B, it is assum 

in Table 2 below. 




Presence Status 

r~mobile phone I: busy 
• mobile phone 2: busy 
PDA: available 
busy 
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----- — :rr=:=r 

devices. . r^^otinn a<; set forth in Table 2, 

When the S-CSCF receives the presence information as to 

U ..«deo .•• men the call will be routed to the use, s PDA. Uo V 
,.„hetou.Mto.heSIPad.es...ip:user@PDA.op— ^w^- 
«,euse,,and»PDA.MaeuUaesthedest.„at,o„a.thedo»a.o^a^^ 
Aseco«dsegment714oftheroutmgscnpt710isdTected 
■ » ■ ...hentheoallwillbehandledmapredefmedmannerfotabusy 
Ae call type « "vcce. then the ca^ w ^ ^^.^^ 

status, such as routing the voice call to avotcema.1 sy t»^ P _ 

.u.QTP address "sip:user@voicemail.operator.com, wno 

.„,herou|ed.o*eSIP^a-- 2 

identifies the user, and voicemaii m „i,own as "busy" or other 

«operator.com." The status shown to such callers may be shown as busy 

appropriate indication. call tvoe caller domain, particular 

hi this mamier, particular attnbutes (e.g., call type, 
..eriden.y(s,,ca„ete,.p»ent.ype,cal,pnotr.e..,a.^^^^^^ 

--^^'-trz::r:drr:b:::.=™^^^^^^ 

requests are routed to the appropn i„p,emented as a 

1 .tf^Ui.tP^ of the communication requests, 
by the particular attnbutes oi me con „,„^ent entity may be 

^ c rSCF or other session management eniuy y 

In some cases, the S-Cbur or ou fiupr criteria 

^.e.„per...nanytypeo.scrip.ing,an.age„owev.— 

20 Nr 56816 U 
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u . t.d- nrioritr trigger points such as header content, presence 

orabsenceofaheader,apamcu .u^ c CSCF dynamically changes the 

^ accordance wiB. one en.Wtaen. of — , ^^^"^ >^ 
fiUe.cri.eriabasedon*e„se,pr«ence.„fo™a„„n,wh.m^^^^ 

----:=-rro::=— 

PC*™.. — anaope..o.U,acco^oe-.ei.^i^^^^^^^ 

Ip^taUve computing tap— on of a se.,on 
.^nso„.o^.onsinaccor<ia„oe.iU,U>einvenUon.suchasa„S-CSCF. 

' The rep— con^uUng a„an,e„e„. .i.a..e for >»*-^^; 

firmware, hard-dnve storage, etc. The storag ^ ^^^^ 

,„.gen.ediatostorepro^a.s,suchasprogrannn*.eROM^^2^ 

'tM:°°"Z«r"do.herhardwarecapah.eofread,„ga„d/or.oHng 
ROM drives, DVD dnves, ana u * nnerations in accordance 

.format.. .oneemhodtaent-softwareforcar^S^^ 
,3 .ithmepresentinvenaonntayhestoredarvddt— onCD^M^^^ 

fc,„,«fn,ediacapah,eofpo,,a..y.toringinforn.a.ro„,.r^-^^^^ 
8.,.Thesestoragemedta,naybein.er.edn,.o,and^b^-ed 

S.hso,twaren.ayaUohetra.n,it.ed,omeco.„pu.mgarr^ge.««^ 
a. being downloaded etectronicaUy via a ne^vork, such as me tatemet 
30 AreaNetwoik(LAN)816,orothernetwork. 
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A 81 2 Store the various programs and data used in 
804. ana/or «.ed,a dev,oe ^ ^ ^ „„,o. «, «,e s»rage 

c„™»tion «>ft me present mvenUon, In *e ^.^ ^ 

,^„™a«o„. Fo.exa»p.e,*es*scnpno„mod„l S20^^ ^^^^ 
_..o..se...o.ep^— ^^^^ 

.-a— ^^^^^^ 

„echanis» or other 

applied. From *e descnpUon provde^ l-- * 
to. te preset invention is equaUy appUcable m a variety 

an^S™™"- ... „f.h^„emolaryembodimentoftheinvention 

The foregoing deserrpUon of the exemplary 

«f illustration and description. It is noi mici 
tobeenpresented f« P"^^" " Many modifications and 

exhanstiveortohmHtheinventionto^repreotseform^^^^ 

variationsarepo^ibleinU^tottheahoveteach. . '^^^^ 
toventi„.belimi.ednotwiththisdetai.eddescnpnon,bu,ratherdefi 

30 appended hereto. 
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